perf: Avoid cloning signatures for simple port checks - #3149

Merging this PR will improve performance by 9.63%

⚡ 9 improved benchmarks
✅ 36 untouched benchmarks

Performance Changes

_{Comparing ab/envelope-perf-2 (238ba09) with main (e0540a1)}

Codecov Report

❌ Patch coverage is 93.50000% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.61%. Comparing base (e609c66) to head (238ba09).
⚠️ Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main    #3149      +/-   ##
==========================================
+ Coverage   81.55%   81.61%   +0.06%     
==========================================
  Files         242      242              
  Lines       47373    47649     +276     
  Branches    40970    41246     +276     
==========================================
+ Hits        38633    38888     +255     
- Misses       6721     6737      +16     
- Partials     2019     2024       +5     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

@codspeedbot explain why this is faster

@codspeedbot explain why this is faster

Why this PR is faster

CodSpeed measures a +14.79% overall improvement, driven by three benchmarks:

Root cause: eliminating whole-Signature allocations on the hot path

Previously, OpType::value_port_count and OpType::port_kind went through dataflow_signature(). For op variants whose signature is synthesized (e.g. DataflowBlock, Case), this built a fresh Signature object on every call — allocating and deep-cloning the TypeRows and Terms inside it — just to read a port count or a single port's edge kind.

This PR introduces the internal ValuePortOp trait (hugr-core/src/ops.rs), dispatched per OpType variant via enum_dispatch, so these queries are answered without materializing the full signature:

• Variants with a cached signature simply expose it (value_port_signature), so counting ports never allocates.
• value_port_kind clones only the single requested port type instead of the entire signature.
• Variants with no value ports get a trivial "zero ports" implementation.

Where the time went

These port queries are extremely hot: port_kind / value_port_count are called throughout HUGR validation (which is ~40% of simple_cfg) and during serialization encoding. In the head flamegraph for simple_cfg, the residual cost of these helpers is now dominated by the unavoidable work — the remaining allocation/clone traffic shows up as Term::clone (7.5% total), its drop_glue (4.3%), and malloc/free churn. Removing the per-call full-signature construction (and the matching allocate + clone + drop of every TypeRow/Term it contained) is what cuts CPU cycles across all three benchmarks.

In short: the speedup comes from not building and immediately discarding a complete Signature for what are really trivial "how many value ports?" / "what kind is this one port?" lookups.

Note: CodSpeed flagged that the base and head runs executed on slightly different CI hardware (EPYC 9V74 vs 7763). In Simulation mode this can shift the estimate a little, but the change here removes real allocation and cloning work, so the improvement is expected to be genuine rather than an artifact of runner variability.

_{Was this response helpful? React with 👍 or 👎 to help us improve CodSpeedBot.}

Refactored the change, adding the new methods to OpTrait instead.

Main concern here is just about duplicating logic in two places (the new method impls, and the old ones that constructs a Signature)

Done, we're using the existing traits now

Shame that this is internal to hugr-core; I don't see why external clients (e.g. some tket2 passes!) wouldn't benefit from the same

It's now in the public trait

Makes me think that we should make something like this be the main way to query a node - I think that means some mix of

• Deprecating signature()
• Changing the type fn signature(&self) -> impl ValuePortThing (...maybe instead of the methods on the op)
• Making Signature implement this trait too, and fn signature just builds it as a cache of what the op methods are returning

Could be interesting, I'll track it in a separate issue since it would be a breaking change.

Note that there is HugrView::{in_,out_,}value_types as well, that calls the "expensive" (sometimes) Signature...maybe they just need updating

Updated!